Skip to content

TST: Call tests just once with --dist=loadscope #28531

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 26 commits into from
Nov 17, 2019
Merged

TST: Call tests just once with --dist=loadscope #28531

merged 26 commits into from
Nov 17, 2019

Conversation

datapythonista
Copy link
Member

Another try to what was tried in #26949. Before this PR the tests are called twice, once in a core for the tests that affect shared results, and once in parallel for the rest.

This PR makes a single call, and tests in the same scope (class or module) are granted to run in the same core, so no shared data problems should happen.

The tests being very slow was possibly caused by the proxy env variables, and not --dist=loadscope. But please check how long tests took before merging.

@datapythonista datapythonista added Testing pandas testing functions or related to the test suite CI Continuous Integration labels Sep 19, 2019
@datapythonista
Copy link
Member Author

If this finally works and can be merged, next step is to reimplement #26932. It failed before in the second run of the tests, but after this is merged, we'll have only one run, and it will work. That will make the clipboard tests run again in the CI.

@datapythonista
Copy link
Member Author

datapythonista commented Sep 20, 2019

There are some tests failing, I guess they use the same shared resources, but are not in the same scope, but the timings look ok.

Comparing times with #28542, those are the results:

Build Original dist=loadscope diff
Linux p35_compat 25m 25m 0
Linux py36_32bit 25m 25m 0
Linux py36_locale_slow 24m 26m +2
Linux py36_locale_slow_old_np 21m 26m +5
Linux py37_locale 26m 25m -1
Linux py37_np_dev 22m 23m +1
Windows py36_np15 25m 26m +1
Windows py37_np141 23m 22m -1
macOS py35_macos 28m 22m -6
travis 3.7 21m 23m +2
travis 3.6, locale 23m 25m +2
travis 3.6, coverage 28m 31m +3
travis 3.6, slow 24m 22m -2

I'll have a look at Linux py36_locale_slow_old_np to see if the increase on time is likely to be caused by the different parallelization of tests implemented here. And split some test files. Or if it's random noise or something else. But for the rest looks like there is no significant increase in time. So, I think it makes sense to move forward with this.

@datapythonista
Copy link
Member Author

Looks like in test_sql.py there are files in different classes that use the same shared resources, so I changed the distribution of the tests to be per file, and not per scope.

I think we'll have to detect the file(s) that are taking longer in Linux py36_locale_slow_old_np and split them. Other than that, this looks good to me (there is an error in the allowed failures in Travis, but I guess it's unrelated).

See updated timings:

Build Original dist=loadscope diff dist=loadfile
Linux p35_compat 25m 25m 0 24m
Linux py36_32bit 25m 25m 0 26m
Linux py36_locale_slow 24m 26m +2 28m
Linux py36_locale_slow_old_np 21m 26m +5 30m
Linux py37_locale 26m 25m -1 26m
Linux py37_np_dev 22m 23m +1 23m
Windows py36_np15 25m 26m +1 25m
Windows py37_np141 23m 22m -1 23m
macOS py35_macos 28m 22m -6 21m
travis 3.7 21m 23m +2 26m
travis 3.6, locale 23m 25m +2 26m
travis 3.6, coverage 28m 31m +3 31m
travis 3.6, slow 24m 22m -2 27m

Copy link
Member

@WillAyd WillAyd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Certainly simpler - this lgtm so I'd say merge if no other feedback and you have follow ups

Copy link
Contributor

@jreback jreback left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i am weary of this let me look

@datapythonista
Copy link
Member Author

Would be nice to get this merged somehow soon, so we can restore the clipboard tests. But this PR is a bit tricky and somehow risky, so let's review well, and re-run the CI couple of times before merging.

Copy link
Contributor

@jreback jreback left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of this change, but I just don't want unexplained failures like we had before when we had resource contention. can you provide some insight on the question below.

@jreback jreback added this to the 1.0 milestone Oct 2, 2019
Copy link
Contributor

@jreback jreback left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok comment on deps; also should followup with a PR removing the marks themselves (single,multiple); let's not crowd this one. pls rebase as well. ping on green.

@jreback
Copy link
Contributor

jreback commented Oct 3, 2019

ok one more rebase; ping on green.

@datapythonista
Copy link
Member Author

Having this error in Travis:

QXcbClipboard::setMimeData: Cannot set X11 selection owner

................................................./home/travis/build/pandas-dev/pandas/pandas/compat/__init__.py:85: UserWarning: Could not import the lzma module. Your installed Python is incomplete. Attempting to use lzma compression will result in a RuntimeError.

  warnings.warn(msg)

/home/travis/build/pandas-dev/pandas/pandas/compat/__init__.py:85: UserWarning: Could not import the lzma module. Your installed Python is incomplete. Attempting to use lzma compression will result in a RuntimeError.

  warnings.warn(msg)

./home/travis/build/pandas-dev/pandas/pandas/compat/__init__.py:85: UserWarning: Could not import the lzma module. Your installed Python is incomplete. Attempting to use lzma compression will result in a RuntimeError.

  warnings.warn(msg)

/home/travis/build/pandas-dev/pandas/pandas/compat/__init__.py:85: UserWarning: Could not import the lzma module. Your installed Python is incomplete. Attempting to use lzma compression will result in a RuntimeError.

  warnings.warn(msg)

=================================== FAILURES ===================================

______________________ test_raw_roundtrip[\U0001f44d...] _______________________

[gw0] linux -- Python 3.6.9 /home/travis/miniconda3/envs/pandas-dev/bin/python

data = '👍...'

    @pytest.mark.single

    @pytest.mark.clipboard

    @pytest.mark.skipif(not _DEPS_INSTALLED, reason="clipboard primitives not installed")

    @pytest.mark.parametrize("data", ["\U0001f44d...", "Ωœ∑´...", "abcd..."])

    def test_raw_roundtrip(data):

        # PR #25040 wide unicode wasn't copied correctly on PY3 on windows

        clipboard_set(data)

>       assert data == clipboard_get()

E       AssertionError: assert '👍...' == ''

E         - 👍...

pandas/tests/io/test_clipboard.py:266: AssertionError

Not sure why this is failing here. Shouldn't be caused by the changes here. Has anyone seen this error before?

@jreback
Copy link
Contributor

jreback commented Oct 4, 2019

@datapythonista are we actually running the x clip tests currently? i thought was part of the issue

@datapythonista
Copy link
Member Author

I thought we moved those tests to azure, where they were skipped. Not sure if the failing build was added after that. I'm in my phone, can't check in detail now.

@jbrockmendel
Copy link
Member

@datapythonista still working on this?

@datapythonista
Copy link
Member Author

Yes, still need to figure out what's the problem with the failing tests, but want to get this merged.

@jreback
Copy link
Contributor

jreback commented Nov 13, 2019

can you rebase when you have some time

@jreback
Copy link
Contributor

jreback commented Nov 16, 2019

it looks like the 3.6 coverage job is taking 50% longer than on master. can you confirm? (45 min)

maybe rebase and see if this repeats.

@jreback jreback merged commit 940ea47 into pandas-dev:master Nov 17, 2019
@jreback
Copy link
Contributor

jreback commented Nov 17, 2019

thanks @datapythonista

let's monitor the CI going forward for any odd failures

@datapythonista
Copy link
Member Author

I created #29671 to speed up the builds.

@jreback
Copy link
Contributor

jreback commented Nov 17, 2019

great

in practice we are already splitting test files if they r too big (in loc)
but this is also a good metric

@alimcmaster1
Copy link
Member

Potentially related seeing this on travis 36 builds

[gw1] linux -- Python 3.6.6 /home/travis/miniconda3/envs/pandas-dev/bin/python
data = '👍...'
    @pytest.mark.single
    @pytest.mark.clipboard
    @pytest.mark.skipif(not _DEPS_INSTALLED, reason="clipboard primitives not installed")
    @pytest.mark.parametrize("data", ["\U0001f44d...", "Ωœ∑´...", "abcd..."])
    def test_raw_roundtrip(data):
        # PR #25040 wide unicode wasn't copied correctly on PY3 on windows
        clipboard_set(data)
>       assert data == clipboard_get()
E       AssertionError: assert '👍...' == ''
E         - 👍...
pandas/tests/io/test_clipboard.py:264: AssertionError

https://travis-ci.org/pandas-dev/pandas/jobs/613141276?utm_medium=notification&utm_source=github_status

https://travis-ci.org/pandas-dev/pandas/jobs/613153228?utm_medium=notification&utm_source=github_status

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI Continuous Integration Testing pandas testing functions or related to the test suite
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants